home *** CD-ROM | disk | FTP | other *** search
/ Floppyshop 2 / Floppyshop - 2.zip / Floppyshop - 2.iso / diskmags / 0022-3.564 / dmg-0082 / 115.txt < prev    next >
Text File  |  1997-04-16  |  12KB  |  292 lines
  1. =========================================================================
  2.  
  3. INFO-ATARI16 Digest         Mon, 29 Jan 90       Volume 90 : Issue  115
  4.  
  5. Today's Topics:
  6.                Monitor Burnout/ Should got a MAGNAVOX!
  7.                     Problem with asm in MEGAMAX-C
  8.                       Sozobon <time.h> question
  9.                Words of wisdom on MWC behaviour needed
  10. ----------------------------------------------------------------------
  11.  
  12. Date: 29 Jan 90 02:24:36 GMT
  13. From: dsl.pitt.edu!pitt!cuphub!kar7481@PT.CS.CMU.EDU  (Dan
  14.  Karbowsky;AtariEliteOfPghPa bbs412-384-5609)
  15. Subject: Monitor Burnout/ Should got a MAGNAVOX!
  16. Message-ID: <3694@cuphub.cup.edu>
  17.  
  18. In article <15294@orstcs.CS.ORST.EDU>, warningm@prism.cs.orst.edu
  19.  (MICHAEL WARNING) writes:
  20. >    My monitor (SM1224) was acting flakey for a week or so when all of the
  21. > sudden it decided to completely die on me.  I traced the problems to what
  22. > seems to be one bad part in the power supply (the board number is TH901).
  23. > could somebody tell me exactly what the thing is and where I can get a new
  24. > one so I can replace it?
  25. >
  26. >                                       Mike Warning
  27. >                                               warningm@prism.cs.orst.edu
  28.  
  29. You Shoulda gotten a MAGNAVOX 14" 8cm515 monitor...
  30. 2 years Parts/Labor included--standard warranty!!!
  31.  
  32. Has ANALOG-RGB, TTL-RGB, and COMPOSITE (I'm on my 124 now watching Cinemax
  33. on my MAGNAVOX....)
  34.  
  35. 640x240 resolution.....great for TV-useage via a VCR or as a monitor.
  36.  
  37.  
  38. BEST PART:   Only runs round $239.00 compared for what I hear mos dealers
  39.             asking for a 1224!
  40.  
  41. Just thought I'd mention an affordable alternative to the netbase....
  42.  
  43.  +-----------------------------------------------------------------------------+
  44.  | Dan Karbowsky      kar7481@pitt!cuphub /   S U P P O R T  T H E  S T ! ! !  |
  45.  | 102 Lee Drive      ___________________/Call the ATARI ELITE of PITTSBURGH'S |
  46.  | Belle Vernon, PA  / BBS (Forem-ST,fnet node 19)  at (412) 384-5609 at 300   |
  47.  | 15012   U.S.A.   / thru 19.2k baud 24 hrs./day 7-days/week   Mention this   |
  48.  |                 / message at logon.                                         |
  49.  +-----------------------------------------------------------------------------+
  50.  
  51. ------------------------------
  52.  
  53. Date: Mon, 29 Jan 90 10:20:47 GMT
  54. From: Michael Mueller <K298027%CZHRZU1A.BITNET@CUNYVM.CUNY.EDU>
  55. Subject: Problem with asm in MEGAMAX-C
  56.  
  57. I'm usually progamming in C, but sometimes I need to code some routines in
  58. assembler. As I am working with the MEGAMAX-C compiler this is very
  59. easy. Now my problem:
  60.  
  61. asm ?
  62. init:   move.l #1234,A0
  63.         move.l #init,A0         ; this is not accepted !!!!!
  64.         bra    init             ; this is OK
  65. ?
  66.  
  67. Why is the second mnemonic not accepted ? Has anybody an idea how to use
  68. labelled adresses ?
  69.  
  70. ---------------
  71. Michael Mueller, Brain Research Institute, Zuerich, Switzerland
  72. EARN/BITNET: K298027@CZHRZU1A.BITNET
  73.  
  74. ------------------------------
  75.  
  76. Date: 29 Jan 90 07:17:20 GMT
  77. From: cs.umn.edu!thelake!steve@ub.d.umn.edu  (Steve Yelvington)
  78. Subject: Sozobon <time.h> question
  79. Message-ID: <0029900117203830@thelake.mn.org>
  80.  
  81. [In article <9001272330.aa22145@BRL-VGR.APG-EMH5.APG.ARMY.MIL>,
  82.      ddavis@APG-EMH5.APG.ARMY.MIL (Dave Davis) writes ... ]
  83.  
  84. >
  85. >       Can anyone supply a short example of working code which uses the
  86. > 'start_timer' and 'time_since' functions?   I've been playing around
  87. > trying to time the execution of some code, but haven't been able to get
  88. > a working program as of yet.  (Probably due to a lack of understanding
  89. > of the correct syntax needed).  Thanks in advance!
  90. >
  91.  
  92. This is why it's good to have a copy of the sources to dLibs, and keep
  93. them handy. timer.c, the module that defines start_timer and time_since,
  94. also includes the source code for two functions that call start_timer and
  95. time_since. For those who don't have the sources, here is the relevant
  96. module:
  97.  
  98. #include <time.h>
  99.  
  100. clock_t clock()
  101. /*
  102.  *      Return current value of 200Hz timer.  This is the ANSI compatible
  103.  *      timer function.  The number of seconds elapsed between two events
  104.  *      can be determined by calling this function twice and dividing the
  105.  *      difference between the two times by CLK_TCK (200L).
  106.  */
  107.         ?
  108.         asm("   clr.l   -(sp)           ");
  109.         asm("   move.w  #$20,-(sp)      ");
  110.         asm("   trap    #1              ");     /* enter supervisor mode */
  111.         asm("   addq.l  #6,sp           ");
  112.         asm("   move.l  $4BA,-(sp)      ");     /* save system clock value */
  113.         asm("   move.l  d0,-(sp)        ");
  114.         asm("   move.w  #$20,-(sp)      ");
  115.         asm("   trap    #1              ");     /* exit supervisor mode */
  116.         asm("   addq.l  #6,sp           ");
  117.         asm("   move.l  (sp)+,d0        ");     /* return system clock value */
  118.         ?
  119.  
  120. clock_t start_timer(t)
  121.         clock_t *t;
  122. /*
  123.  *      Start a 200Hz timer.  This timer value can later be checked with
  124.  *      time_since() to determine elapsed time.  These functions provide
  125.  *      a very low-overhead way of timing events.
  126.  */
  127.         ?
  128.         asm("   clr.l   -(sp)           ");
  129.         asm("   move.w  #$20,-(sp)      ");
  130.         asm("   trap    #1              ");     /* enter supervisor mode */
  131.         asm("   addq.l  #6,sp           ");
  132.         asm("   move.l  $4BA,-(sp)      ");     /* save system clock value */
  133.         asm("   move.l  d0,-(sp)        ");
  134.         asm("   move.w  #$20,-(sp)      ");
  135.         asm("   trap    #1              ");     /* exit supervisor mode */
  136.         asm("   addq.l  #6,sp           ");
  137.         asm("   move.l  (sp)+,d0        ");
  138.         asm("   move.l  $8(a6),a0       ");     /* grab pointer to timer */
  139.         asm("   move.l  d0,(a0)         ");     /* return clock value */
  140.         ?
  141.  
  142. clock_t time_since(t)
  143.         clock_t *t;
  144. /*
  145.  *      Returns the number of 200Hz ticks since start_timer() was called
  146.  *      for timer <t>.
  147.  */
  148.         ?
  149.         asm("   clr.l   -(sp)           ");
  150.         asm("   move.w  #$20,-(sp)      ");
  151.         asm("   trap    #1              ");     /* enter supervisor mode */
  152.         asm("   addq.l  #6,sp           ");
  153.         asm("   move.l  $4BA,-(sp)      ");     /* save system clock value */
  154.         asm("   move.l  d0,-(sp)        ");
  155.         asm("   move.w  #$20,-(sp)      ");
  156.         asm("   trap    #1              ");     /* exit supervisor mode */
  157.         asm("   addq.l  #6,sp           ");
  158.         asm("   move.l  (sp)+,d0        ");
  159.         asm("   move.l  $8(a6),a0       ");     /* grab pointer to timer */
  160.         asm("   sub.l   (a0),d0         ");     /* return elapsed time */
  161.         ?
  162.  
  163. sleep(dt)
  164.         int dt;
  165. /*
  166.  *      Suspend operation for <dt> seconds.  This is implemented as a
  167.  *      start_timer()/time_since() tight loop waiting for the specified
  168.  *      amount of time to pass.  In a multi-tasking environment, this
  169.  *      function should be replaced by a call which will de-activate
  170.  *      this task for a period of time, allowing other tasks to run.
  171.  */
  172.         ?
  173.         clock_t t, start_timer(), time_since();
  174.         register clock_t tt;
  175.  
  176.         tt = ((clock_t) dt) * CLK_TCK;
  177.         start_timer(&t);
  178.         while(time_since(&t) < tt)
  179.                 ;
  180.         ?
  181.  
  182. usleep(dt)
  183.         int dt;
  184. /*
  185.  *      Suspend operation for <dt> microseconds.  Works like sleep().
  186.  */
  187.         ?
  188.         clock_t t, start_timer(), time_since();
  189.         register clock_t tt;
  190.  
  191.         tt = ((clock_t) dt) * (CLK_TCK / ((clock_t) 100));
  192.         start_timer(&t);
  193.         while(time_since(&t) < tt)
  194.                 ;
  195.         ?
  196. --
  197.    Steve Yelvington at the (thin ice today*) lake in Minnesota
  198.    UUCP path: ... umn-cs.cs.umn.edu!thelake!steve
  199.  
  200.    *16 cars through the ice so far this year! Yes, you, too, can
  201.     have that sinking feeling....
  202.  
  203. ------------------------------
  204.  
  205. Date: 29 Jan 90 07:34:50 GMT
  206. From: cs.umn.edu!thelake!steve@ub.d.umn.edu  (Steve Yelvington)
  207. Subject: Words of wisdom on MWC behaviour needed
  208. Message-ID: <0029900134503832@thelake.mn.org>
  209.  
  210. [In article <20216@watdragon.waterloo.edu>,
  211.      swklassen@tiger.waterloo.edu (Steven W. Klassen) writes ... ]
  212.  
  213. > In article <633294579.26980@myrias.com> mj@myrias.com (Michal Jaegermann)
  214.  writes:
  215. >>
  216. >>All test programs work beautifuly, echoing nicely input, until they
  217. >>hit exit(). THE CRASH does not happen when there are run under msh, OR
  218. >>when run under msh or gulam but were compiled with MWC-zed dLibs
  219. >>libraries.  But I need a floating point, which dLibs does not support.
  220. >>An attempt to use MWC printf with dLibs was partially successful in
  221. >>that the the program behaves nicely and exits in a clean manner but it
  222. >>does not print anything at all (probalby due to incompatible internal
  223. >>structures).
  224. >
  225. > To be honest I had a hard time understanding your post.  Perhaps you
  226. > could repost, rewording things so it is a bit clearer.
  227. >
  228. > One thing that I did understand is that you are having a problem
  229. > printing floating point from MWC.
  230.  
  231. No, that's not what he said, and that's not the problem at all.
  232.  
  233. The floating-point problem stems from a version of dLibs converted for the
  234. Mark Williams compiler. The use of dLibs was an attempt to avoid a system
  235. crash that appeared to come from the MWC exit() function.
  236.  
  237. Michal wrote:
  238.  
  239. >Setting:  Mega ST with TOS 1.4, gulam shell and MWC 3.0.6 compiler.
  240. >Any program compiled with supplied MWC libraries which reads stdin.
  241. >
  242. >An attempt to redirect on a command line stdin to come from a file
  243. >causes an 'exit()' routine to bomb out in the most interesting and
  244. >unusual manner.
  245.  
  246. This gets down to the issue of redirected file handles that has been
  247. mentioned recently in posts from Dale Schumacher, Allan Pratt and Ken
  248. Badertscher.
  249.  
  250. The GEMdos way of redirecting standard file handles, Fforce(), is
  251. unreliable at best and broken at worst. I've had all sorts of horrible
  252. things happen lately because of it, *including* running out of memory. On
  253. more than one occasion I've even been unable to launch coldboot.prg to
  254. slap the system out of its silly state.
  255.  
  256. Mark Williams uses a strange method of passing extended arguments that
  257. encodes redirection in environment variables. The child process then
  258. handles any necessary redirection. The parent does not call Fforce() and
  259. then exec the child.
  260.  
  261. MWC's workaround requires that both the parent and the child know about
  262. the method and agree to use it. When you launch an MWC-compiled program
  263. with the Mark Williams msh shell, the parent and child agree. If the
  264. parent is not msh or running under msh, tough cookies.
  265.  
  266. Apparently gulam uses Fforce() to redirect input. There may be something
  267. in the MWC exit() code that pushes TOS over the (very narrow) edge. You
  268. might escape the grim reaper by calling _exit() or Pterm(). (Perhaps Dan
  269. Glasser can provide some insight?)
  270.  
  271. Dale and John Stanley and J. Bammi have been kicking around a really nifty
  272. (if you like black magic) workaround that allows the parent to cleverly
  273. change file handles around **in the child's context** just before the
  274. child begins to run. It appears to fix ALL these problems without
  275. requiring that the child process know anything about the method.
  276.  
  277. I'm not going to even try to describe how it works, but since kbad has
  278. more or less publicly blessed it, perhaps Dale or John will post some
  279. code.
  280.  
  281. --
  282.    Steve Yelvington at the (thin ice today*) lake in Minnesota
  283.    UUCP path: ... umn-cs.cs.umn.edu!thelake!steve
  284.  
  285.    *16 cars through the ice so far this year! Yes, you, too, can
  286.     have that sinking feeling....
  287.  
  288. ------------------------------
  289.  
  290. End of INFO-ATARI16 Digest V90 Issue #115
  291. *****************************************
  292.